Since the past, a technology has been known in which a mobile terminal having a plurality of interfaces communicates with a correspondent node while moving between a plurality of different communication networks. The different communication networks are, for example, a third generation (3G) cellular network and a wireless local area network (WLAN). Two different communication networks are used in the descriptions below. However, the communication networks are not limited to two different communication networks. Many more different communication networks can also be used. The different communication networks here refer to, for example, communication networks with different types of wireless connections (communication networks actualizing a handover between different types of networks) and communication networks with different administrators (communication networks actualizing roaming). As shown in FIG. 12, a mobile terminal 10 (mobile node [MN]) having two interfaces, one for the 3G cellular network (also referred to, herein, as simply 3G) and another for the WLAN, communicates while moving over an area configured by the 3G and the WLAN. Context transfer protocol (CTP) (refer to Non-patent Document 1, below) is proposed for a seamless, fast handover such as this. It is preferable for a mobile node user if communication can be performed in a state of constant connection and at a higher data rate when required.
Here, conventionally, when the MN 10 performs a handover, the MN 10 is required to perform all processes in a protocol flow to receive service (internet protocol security association [IPsec SA] among the MN 10, an access router [AR], a correspondent node [CN: correspondent node], and a home agent [HA]; quality of service [QoS] state securement between the MN 10 and a QoS Next Steps in Signaling [NSIS] entity [QNE] that is a router recognizing NSIS QoS; header compression [HC]; and the like), as shown in FIG. 13. However, a large load is applied when the processes are performed from the beginning, thereby requiring processing time. Therefore, the above-described CTP is used. The CTP assumes that context data (CTD) remains held between the MN 10 and an AR to which the MN 10 connects. The CTD is information on an environment set between the MN 10 and the AR, and the like. The CTD refers to, for example, authentication authorization accounting (AAA) information, information related to QoS, header compression information, and information on IPsec SA and the like among the MN 10, the AR, and the CN.
As shown in FIG. 14, the MN 10 and a previous AR (pAR) hold context information related to the CTD between the MN 10 and the pAR. The pAR is an AR before movement of the MN 10. When the MN 10 performs a handover, the MN 10 transmits a context act request (CTAR) to a new AR (nAR) based on a certain trigger. The nAR is an AR at a new connection destination. The CTAR instructs the nAR to acquire the CTD from the pAR. At this time, the CTAR can include information related to the pAR, context information, and the like. The nAR that has received the CTAR transmits a CT-req to the pAR. The CR-req indicates a CTD acquisition request. The pAR transmits the CTD held by the pAR itself to the nAR, based on the reception of the CT-req. As a result, a required protocol state can be quickly re-established without all processes of the protocol flow being performed from the beginning. The method can also be actualized when the MN 10 or the pAR does not hold context information, such as that described above. However, in this case, it is assumed that trust exists among the three parties, the MN 10, the pAR, and the nAR.
Other methods for circumventing the above-described problem of time being required because of the conventional handover will be described with reference to FIG. 15. As shown in FIG. 15, the MN 10 starts the handover based on a certain trigger. At this time, the MN 10 transmits a CTAR to the pAR. The pAR that has received the CTAR transmits a candidate access router discovery (CARD) req to a CARD database. The CARD database holds CARD information (refer to Non-patent Document 2, below). The CARD req is an acquisition request for acquiring the CARD information. The pAR acquires the CARD information through a CARD reply from the CARD database. The CARD information refers to information used to predict information on an AR that becomes a candidate for a next connection destination of the MN 10, and the like. The pAR transmits the CTD to the nAR based on the CARD information. Then, when the MN 10 completes the handover, the MN 10 transmits a CTAR (for confirmation) to the nAR. As a result, the CTD may be transmitted to the nAR before the handover is completed. The required protocol state can be re-established more quickly.
Non-patent Document 1: J. Loughney (editor) et al., “Context Transfer Protocol (draft-ietf-seamoby-ctp-11.txt)”, Internet Draft, Internet Engineering Task Force, Work in Progress.
Non-patent Document 2: Marco Liebsch (editor) et al., “Candidate Access Router Discovery (draft-ieft-seamoby-card-protocol-08.txt)”, Internet Draft, Internet Engineering Task Force, Work in Progress.
However, the handover performed by the MN 10 requires time. In other words, time is required to search a layer 1, re-establish a protocol state of a layer 2, re-establish protocol states of a layer 3 and higher layers, and the like. Moreover, a hot spot covered by the WLAN may not be disposed within the 3G. In other words, the nAR may be present at a significant distance from the pAR. As can be seen in computer processing (refer to Non-patent Document 1, above), when the CTD becomes dormant (enters a dormant state) after an elapse of a predetermined amount of time to conserve resources such as main memory, and subsequently expires after further elapse of a predetermined amount of time, the CTD does not expire in a situation shown in FIG. 16A because the pAR transmits the CTD to the nAR before the CTD expires. However, the CTD expires in a situation shown in FIG. 16B because the predetermined amount of time elapses before the CTD from the pAR reaches the nAR. In this way, when the pAR is present at a significant distance (far) from the nAR, a situation such as that shown in FIG. 16B may occur. When the CTD expires because CTD transfer is unsuccessful, the protocol state is required to be re-established (set up) as shown in FIG. 17. Time is required, and communication cannot be performed at a requested data rate.